Lambda the Ultimate

Just came across this discussion of the Deikto component of Chris Crawford's Erasmatron storytelling engine:

Erasmatron 4 is being built around Deikto, a radical new approach to user interface. The concept harkens back to the concepts I originally built into the game "Trust & Betrayal" 15 years ago, but now I am taking it much further. The user builds commands by building sentences on the screen using popup menus.

Not sure if it is really that radical, but I thought it might be of interest to the LtU readership.

Hi, Has anyone made any forum filtering software for LtU? There's a bit more traffic lately and there are a few things I'd like to omit: posts older than a few days, posts less than a fixed size, or by poster.

I imagine a greasemonkey script (or something similar) could pull out the posts and XSLT them. If you've done anything like this, or are interested let me know

Odersky and Zenger - Scalable Component Abstractions

We identify three programming language abstractions for the construction of reusable components: abstract type members, explicit selftypes, and modular mixin composition. Together, these abstractions enable us to transform an arbitrary assembly of static program parts with hard references between them into a system of reusable components. The transformation maintains the structure of the original system. We demonstrate this approach in two case studies, a subject/observer framework and a compiler front-end.

This is pretty cool stuff. It reminds me in some ways of the PLT Scheme units + mixins system described in Modular OO Programming With Units and Mixins, but it feels to me like this supports a much more natural programming style. (Obviously that's a subjective judgement, but what bothered me about the PLT system, at least as described in that paper, is the need to define units and stitch them together in order to define even simple mixin composition. It seems like a much too common operation to require that degree of plumbing, but maybe I didn't quite understand it.)

Anyway, I like it. (And, for Leon Smith, this is an eminently practical technique, motivated with very clear examples. I think most Java programmers would immediately "get" this.)

I read today a rant on pedadogical philosophy by Doron Zeilberger via Philip Wadler's web log.

The first one, due to my colleague and hero Israel Gelfand, I will call the Gelfand Principle, which asserts that whenever you state a new concept, definition, or theorem, (and better still, right before you do) give the SIMPLEST possible non-trivial example. For example, suppose you want to teach the commutative rule for addition, then 0+4=4+0 is a bad example, since it also illustrates another rule (that 0 is neutral). Also 1+1=1+1 is a bad example, since it illustrates the rule a=a. But 2+1=1+2 is an excellent example, since you can actually prove it: 2+1=(1+1)+1=1+1+1=1+(1+1)=1+2. It is a much better example than 987+1989=1989+987.

While writing a reply on LTU, I thought about modifying this principle to programming language design: If an example has a solution that is nearly as good without a given language feature, then that example is not a good motivation for that feature. Perhaps not following this principle is partly what earned FP it's ivory tower reputation.

Researchers love to generalize the heck out of any given feature, to add linguistic support for minor issues, etc. etc. It seems that as a result, PL researchers, particularly FP researchers, have a (deserved and undeserved) reputation for solving problems that aren't really there.

I'm not suggesting that every exploration must be practically motivated. Indeed, it's fun and educational to explore what can be done for its own sake. Was laziness ever practically motivated? I'm not aware that it was, but it certainly lead to some very important breakthroughs, most significantly how to satisfactorily deal with impure effects in a pure language.

However, when it comes to promoting a given language for wider use, features should be chosen to solve practical programming problem, preferably the problems that a niche finds unsatisfactory. (Or should find unsatisfactory... customers usually don't know what they need.)

What practical problems in what niches are LTU readers aware of?

In Haskell, data structure elements are memoized. That is, the function that creates say, an element of a list is called at most once. After the first evaluation, the resulting value is saved away in case it is ever needed again. This is great for things like the infinite list of Fibonacci numbers...

fibs = 1 : 1 : zipWith (+) fibs (tail fibs)

...but it can lead to excessive memory in situations like...

main = print (length list, sum list)
list = [1..10000000]

...where at some point the entire list will need to be in memory. You could have avoided the large memory usage by traversing the list in a linear way, building up the length and sum at the same time, rather than in sequence.

Now imagine an evaluation régime, where instead of memoizing each data element (for later use), we call all of the functions which have a pointer to this element. Afterwards, no more pointers to this element will exist, so we can reclaim its memory. It changes the rule "evlaute a data item at most once" into "evaluate a data item as most once, and be sure to call anything that depends on it immediately, because it is short lived". Is there a name for this evaluation strategy, and any programming languages which implement it?

I just released my new metaprogramming-oriented system (JVM version):

MetaPlatform

Since DSL (Domain Specific Language) is almost an everyday topic for many programmers, I wonder how should a working programmer proceed to define and acturally use a formal semantics for her DSL? I do not mean a group of equations in LaTeX, but an effective method to help to reason about the programs within reasonable constraints for common projects. (Or, is there even bigger advantage to be taken?) To be specific, I was wondering if coq and isabelle and nusmv alike are usable for common projects? Is the cost (exclude the cost of learning) too high? And why? Thank you!

Came across this on Freshmeat:

Amber: "Amber for Parrot is a scripting language for the » Parrot virtual machine. It combines the traditional advantages of scripting languages with support for software correctness and large-scale software engineering."

It's described in self-deprecating terms, but it's interesting in several ways:

• Built in Eiffel and inspired by Eiffel
• Targeting the Parrot VM instead of Java's
• Implements "contract hardening" which sounds intriguing
• Not just another functional programming language, of which there are so many...
• I heard about it before LtU did

Ken Meltsner

Interpreting the Data: Parallel Analysis with Sawzall

"The query language, Sawzall, operates at about the level of a type-safe scripting language. For
problems that can be solved in Sawzall, the resulting code is much simpler and shorter – by a
factor of ten or more – than the corresponding C++ code in MapReduce."

ObjectiveCLIPS is a new programming environment designed for Cocoa, the native Mac OS X object system. ObjectiveCLIPS's originality come from the fact that it integrates the CLIPS expert system shell with Apple's Core Data technology and F-Script, allowing the creation of intelligent Cocoa applications with persistent object models and complex business rules. Developers can easily embed ObjectiveCLIPS in their application and take advantage of its inference engine and associated tools to implement their application logic. ObjectiveCLIPS unifies CLIPS facts with Objective-C Core Data objects, and allows for the manipulation of these objects in rules with the Cocoa-based F-Script language.

ObjectiveCLIPS is an open source software.